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Dear Sir: 

Applicants request review of the rejection in the above-identified application. No amendments 
are being filed with this request. This request is being filed with a notice of appeal. The review is 
requested for the reasons stated below. 

Claims 1-2, 4-20, 30-41 and 48-49 and 51-79 are pending in the application. Reconsideration of 
the present case is earnestly requested in light of the following remarks. Please note that for brevity, only 
the primary arguments directed to the independent claims arc presented, and that additional arguments, 
e.g., directed to the subject matter of the additional dependent claims, will be presented if and when the 
case proceeds to Appeal. 

The Examiner rejected claims 1, 2, 4-13, 15, 17-20, 30-37, 39, 48, 49, 51-59, 61, 63, 65-74, 76 
and 78 under 35 U.S.C. § 102(e) as being anticipated by Weisman et al. (U.S. Publication 2002/01 12058) 
(hereinafter "Weisman"). Applicants respectfully traverse this rejection for at least the reasons below. 

Regarding claim 1, Weisman fails to disclose that each of the plurality of peer nodes is 
further configured to access another of the plurality of peer nodes on the network using the unique 
peer identifier of the other peer node, wherein the peer node does not use a network address of the 
other peer node to access the other peer node . The Examiner cites paragraphs 863-904 of Weisman. 
However, the cited passage does not describe a peer node accessing another peer node using the unique 
peer identifier of the other peer node, wherein the peer node does not use a network address of the other 
peer node to access the other peer node. Instead, this passage describes the contents of the NOTIFY 
multicast message that a device broadcasts when added to the network. 

Weisman teaches that to access another device, messages are sent to the device's control URL, 
which is a combination of the network URL of the device and a unique identifier for the particular target 
service on the device. Specifically, Weisman teaches that a service's control URL includes the path to the 
device, the UDN of the device, the service ID and a randomly generated string (Weisman, paragraphs 
122, 130-137, 815, and 1148 - 1150). Since a device's control URL is not independent of, and clearly 
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uses, the network address of the device, Weisman fails to teach a peer node accessing another peer node 
using the unique peer identifier of the other peer node, wherein the peer node does not use a network 
address of the other peer node to access the other peer node. 

In the response to arguments, the Examiner cites paragraphs 45, 122, 131-137, 183 and 376 of 
Weisman and describes how Weisman' s Web Server invokes an automation proxy for a service to cause 
the service to execute a control request. The Examiner states Weisman' s device host API sets up control 
URL's of hosted devices to point to the Web Server. The Examiner further describes how Weisman's 
system format the URL and uuid that make up the address used to invoke control requests on the service 
object. 

However, the Examiner's remarks actually support Applicants' argument. The Examiner 
states that "Weisman discloses the Device Host API sets up the control URLs of hosted devices 108-1 10 
to point to the Web Server, when the Web Server receives an HTTP request with one of the hosted 
devices ' control URLs, the Web Server invoke[s] the Automation Proxy for the service to execute the 
control request" (italics, added). Thus, the Examiner states that the URL a hosted device is used to access 
a hosted device via the Web Server on the same machine as the hosted device. Thus, in Weisman's 
system a network address (URL) is used when one peer is accessing another. The fact that Weisman's 
system also includes other information, such as the uuid does not change the fact that a network address is 
also used. 

Anticipation requires the presence in a single prior art reference disclosure of each and every 
limitation of the claimed invention, arranged as in the claim . M.P.E.P 2131; Lindemann Maschinenfabrik 
GmbHv. American Hoist & Derrick Co., 221 USPQ 481, 485 (Fed. Cir. 1984). The identical invention 
must be shown in as complete detail as is contained in the claims. Richardson v. Suzuki Motor Co., 9 
USPQ2d 1913, 1920 (Fed. Cir. 1989). As discussed above, Weisman fails to disclose where each of the 
plurality of peer nodes is further configured to access another of the plurality of peer nodes on the 
network using the unique peer identifier of the other peer node, wherein the peer node docs not use a 
network address of the other peer node to access the other peer node . Therefore, Weisman cannot be said 
to anticipate claim 1 . 

Thus, for at least the reasons above, the rejection of claim 1 is not supported by the cited art and 
removal thereof is respectfully requested. Similar remarks apply to claims 30, 48 and 66. 

Regarding claim 2, Weisman fails to disclose where each of the plurality of peer nodes is further 
configured to bind a peer identifier corresponding to the particular peer node to the network address of the 
particular peer node . The Examiner cites paragraphs 181-124 of Weisman. The cited passage describes 
the addressing within Universal Plug-n-Play (UPnP) networking. Weisman teaches that a device may use 
an automatic IP addressing facility to obtain an address. However, the cited passage does not mention 
any peer nodes configured to bind a peer identifier corresponding to the particular peer node to the 
network address of the particular peer node. Instead, the cited passage only describes how a peer node 
may automatically obtain, such as via DHCP, an IP address. Weisman does not describe any peer node 
binding a peer identifier to a network address of a particular peer node. 

In the response to arguments, the Examiner cites paragraphs 833 - 837 of Weisman referring to 
Weisman's mapping of a device's DNS name to its IP address. However, the cited passages make no 
mention of a peer node binding a peer identifier of another peer node to the network address of the other 
peer node. Instead, Weisman describes how a computer that needs to contrast a device may use a DNS 
query to discover the devices IP address. Merely discovering an IP address of another device cannot be 
considered binding a peer identifier to a network address. Weisman states that the DNS mappings are 
used to ensure that the device can still be found even when the IP address changes (Weisman, paragraphs 
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834 - 835). Thus, Weisman teaches that a computer should lookup IP addresses using a DNS server 
specifically because IP address may change and the devices name can be used to lookup a changed IP 
address. Weisman's peers clearly do not bind network address to peer identifiers. 

Thus, the rejection of claim 2 is not supported by the cited art and removal thereof is respectfully 
requested. Similar remarks also apply to claims 3 1 , 49 and 67. 

Regarding claim 5, Weisman fails to disclose wherein, to access the other peer node, the unique 
peer identifier of the other peer node is configured to be mapped to one of the one or more network 
interfaces of the other peer node . The Examiner cites paragraphs 7 and 63 of Weisman. However, 
neither of these paragraphs describes a peer identifier being mapped to a network interface of the other 
peer node. Instead, paragraph 7 describes a device hosting framework that listens for control requests and 
translates control requests into calls to the service objects' programming interfaces (e.g. IDispatch 
interfaces). Paragraph 63 describes that service interfaces are written in UTL in service descriptions and 
how a hosted device provides a COM object that exposes the service's interface. Thus, the Examiner has 
failed to cite any portion of Weisman that discloses that the unique peer identifier of the other peer node 
is configured to be mapped to one of the one or more network interfaces of the other peer node . 
Moreover, nowhere does Weisman describe that a service's UDN, which the Examiner equates to the 
unique peer identifier Applicants' claims, is configured to be mapped to a network interface of a peer 
node. 

In the response to arguments, the Examiner cites paragraphs 36, 37, 67 and 67 of Weisman. The 
Examiner argues that Weisman's system translates control requests into calls to a service's dispatch 
interfaces. However, translating control requests into calls to the service objects' programming interfaces 
(e.g. IDispatch interfaces) does not disclose a unique peer identifier of a peer node configured to be 
mapped to a network interface of the peer node. A programming interface is not a network interface. 
Weisman teaches that the Device Host listens for and receives control requests and then locates and calls 
the dispatch interface for the hosted service. Weisman describes a hosted device as a software module 
that executes on the same machine as the Device Host. Thus, the translation referred to by the Examiner 
clearly involves the Device Host programmatically invoking the service interface of a hosted device. 
The Device Host does not translate the control into a network interface nor does it map a UDN to a 
network interface. 

Thus, the rejection of claim 5 is not supported by the cited art and removal thereof is respectfully 
requested. Similar remarks also apply to claim 52. 

Regarding claim 8, Weisman fails to disclose wherein each of the plurality of peer nodes is 
assigned a different unique peer identifier in accordance with the peer-to-peer platform for each of the one 
or more peer groups in which the peer node is a member peer. The Examiner refers to Weisman's 
container identifier, citing paragraphs 85, 105 and 489. However, Weisman only teaches that a container 
is a string that identifies the group to which the device belongs and that all devices with the same 
container identifier will be hosted in the same process. Nowhere does Weisman mention that each peer 
node is assigned a different unique peer identifier for each of the peer groups in which the peer node is a 
member peer. Weisman merely states that a container identifier identifies the group to which a device 
belongs. Thus, Weisman clearly fails to disclose wherein each of the plurality of peer nodes is assigned a 
different unique peer identifier in accordance with the peer-to-peer platform for each of the one or more 
peer groups in which the peer node is a member peer. 

In the response to arguments, the Examiner cites paragraphs 1513 and 1539 of Weisman and 
refers to Weisman's event subscription process. Weisman teaches that a service may publish event 
messages to interested control points, called subscribers (paragraph 1497). The Examiner refers to the 
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fact that if a subscription expires, the subscription identifier becomes invalid and the control point sends a 
subscription message to get a new subscription identifier. First of all, Weisman's subscription identifiers 
have nothing to do with the container identifiers that the Examiner relies upon in the rejection of claim 8. 
Furthermore, the fact that each subscriber is provided with a unique subscription identifier has no 
relevance to a peer node being assigned a different unique peer identifier for each peer group in which the 
peer node is a member. Weisman's event publishing does not have anything to do with peer group 
membership. 

Therefore, the rejection of claim 8 is not supported by the cited art and removal thereof is 
respectfully requested. Similar remarks also apply to claims 55 and 70. 



The Examiner rejected claims 1-20, 30-41 and 48-79 under the judiciary created doctrine of 
obviousness-type double patenting as being unpatentable over claims of U.S. Patent No. 7,065,579. 
Applicants traverse this rejection on the grounds that the Examiner has not stated a proper prima facie 
rejection. 

The Examiner supports this rejection by stating that "the applications are claiming common 
subject matter" and listing three claim terms that the Examiner asserts are common to both the instant 
application and the '579 patent. The Examiner also states that the '679 patent does not claim the service 
layer as in the instant application, but asserts that it would have been obvious "that the mechanism for 
accessing services of [the] '579 patent is ... similar in functionality to the service layer of the instant 
application." However, stating that the applications claim "common subject mater" and similar 
functionality is not a proper reason for holding the claims of the present application obvious from the 
claims of the listed applications. The Examiner's assertions are completely conclusory. 

According to MPEP 804.II.B.1, "the analysis employed in an obviousness-type double patenting 
determination parallels the guidelines for a 35 U.S.C. 103(a) rejection." This section of the MPEP also 
states that the same "factual inquires . . . that are applied for establishing a background for determining 
obviousness under 35 U.S.C. 103(a) are employed when making an obviousness-type double patenting 
analysis." MPEP 804.II.B.1 also states that the Examiner should list the differences between each 
rejected claim and the claims of the other patent/application, and for each difference the Examiner should 
give the reasons why a person of ordinary skill in the art would conclude that the invention defined in the 
claim is an obvious variation of the invention defined in a claim of the other patent/application. 

Simply stating that the instant application and the '579 patent claim "common subject matter" and 
are "similar in functionality" is not a valid reason why a person of ordinary skill in the art would conclude 
that the invention defined in each claim is an obvious variation of the invention defined in a claim of the 
other patent/application. Nor has the Examiner specifically addressed each difference of each claim of 
the present application compared to the claims of the other applications. Instead, the Examiner 
improperly lumped all the claims together and did not address each specific difference. The Examiner 
clearly has not met the requirements stated in MPEP 804.II.B. 1 to establish a prima facie obviousness- 
type double patenting rejection. Accordingly, Applicants respectfully request removal of the double 
patenting rejection of claims 1-20, 30-41 and 48-79. 

Applicants also assert that the rejection of numerous ones of the dependent claims is further 
unsupported by the cited art. However, since the rejection has been shown to be unsupported for the 
independent claims, a further discussion of the dependent claims is not necessary at this time. 

In light of the foregoing remarks, Applicants submit the application is in condition for allowance, 
and notice to that effect is respectfully requested. If any extension of time (under 37 C.F.R. § 1.136) is 
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necessary to prevent the above referenced application from becoming abandoned, Applicants hereby 
petition for such an extension. If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert & Goetzel PC Deposit Account No. 501505/5760-02000/RCK. 

Also enclosed herewith are the following items: 
^ Notice of Appeal 



Respectfully submitted, 

/Robert C. Kowert/ 

Robert C. Kowert, Reg. #39,255 
ATTORNEY FOR APPLICANT(S) 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: January 18. 2007 
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